Signalling in Modern Telecommunications Systems
In modern switched telecommunication systems (in particular, modern PSTNs) it has become common practice to provide two related but separate network infrastructures: a bearer or transmission network for carrying end-user voice and data traffic, and a signalling network for controlling the setup and release of bearer channels through the bearer network in accordance with control signals transferred through the signalling network. In practice such signalling networks comprise high-speed computers interconnected by signalling links; computer programs control the computers to provide a set of operational and signalling functions in accordance with a standardized protocol. One example of such a signalling protocol is the afore-mentioned Signalling System No. 7 (SS7) which is extensively deployed for control of telephone and other data transmission networks. An SS7 network basically comprises various types of signalling points, namely, signalling end points (SEPs) and signalling transfer points (STPs) interconnected by signalling links, the SEPs being associated for example with respective service switching points (SSPs) of the transmission network, and with service control points (SCPs).
Referring to FIG. 1, an SS7 network 10 is shown inter-communicating three signalling end points constituted by two service switching points SSPs 11 (between which extend speech circuits 12 of a transmission network not further illustrated) and a service control point SCP 13. The SCP serves to implement particular services (sometimes called IN, or Intelligent Network, services) in response to service requests received from an SSP, such a service request being generated by an SSP upon certain trigger conditions being met in the SSP in respect of a call that it is handling. A typical service may involve the translation of the dialer number (called party number) to a different number, the SCP returning this latter number to the SSP to enable the latter to complete call setup.
The SS7 network 10 includes two pairs 14 of signalling transfer points STPs, and a plurality of link sets 18 interconnecting the SSPs, SCP and STPs into a redundant network. Each signalling link set 18 is made up of one or more individual signalling links, the number of signalling links in a link set being chosen to provide appropriate capacity for the level of signalling traffic expected. The redundancy provided in respect of the STPs and links is to ensure that the failure of a single component of the network core does not cause the whole network to fail.
It should be noted that an SS7 network will typically comprise more STP pairs, SSPs and SCPs than illustrated. Service control functionality, as well as being provided in an SCP, can be provided in an Adjunct directly connected to an SSP.
Messages traversing the links of the network may be any of a large number of different types, depending on the nature of the call to which the message relates and the function specified by the message.
The SS7 Architecture
In order to facilitate an understanding of the present invention, a brief review will be given of the layered structure of the SS7 architecture and of the messages passed over the links of the network 10 to implement the SS7 architecture.
FIG. 2 illustrates the SS7 architecture. Levels 1 to 3 (referenced 21, 22, 23) form the message transfer part (MTP) 24. The MTP 24 is responsible for transferring signalling information between signalling points in messages. Level 4 (not referenced as a whole) comprises circuit-related user parts, namely ISDN User Part (ISUP) 26 and Telephone User Part(TUP) 27. These user parts define the meaning of the messages transferred by the MTP 24 and provide functionality to the users of SS7 (block 29). The user parts 26 and 27 are specific to particular types of circuit-related applications as indicated by their names. In fact, the ISUP is the most important user part, the TUP being a subset of ISUP and having been largely replaced by the latter. Most inter-exchange signalling (such as between SSPs 11 in FIG. 1) is circuit-related signalling using ISUP messages.
As well as the circuit-related user parts, SS7 level 4 also includes functional elements defining a general protocol for non-circuit-related information, such as operations, maintenance and administration information or network database information. The main functional element in this Level 4 protocol is the Transaction Capabilities (TC) 30 which sits on top of a Signalling-Connection-Control Part (SCCP) 31 and beneath a TC Users element 32.
The SCCP 31 actually forms part of the transfer mechanism for non-circuit-related applications, combining with MTP 24 to provide transfer mechanisms (both connectionless and connection oriented) meeting the Open Systems Interconnection (OSI) Layer 3/4 boundary requirements. TC 30 itself comprises two elements, namely an intermediate-services part (ISP) and a transaction-capabilities application part (TCAP); ISP is only used for connection-oriented services. Users of the SCCP/TC stack include the INAP (Intelligent Network Application Part) 32 and MAP (Mobile Application Part) 33. With reference to FIG. 1, messages passed between an SSP 11 (FIG. 1) and SCP 13 will be INAP messages using SCCP/TC (in fact, such messages are generally concerned with real time query/response transactions for which a connectionless service is most appropriate so that only the TCAP part of TC is used). Non circuit-related inter-exchange signalling also use SCCP/TC messages; for example, to implement a callback-when-free service, the originating and destination exchanges may exchange SCCP/TC messages. It should also be noted that ISUP may use the SCCP for certain messages.
Considering the MTP 24 in a little more detail, Level 1 (reference 21) defines the physical, electrical and functional characteristics of the transmission path for signalling. MTP Level 2 (reference 22) defines the functions and procedures for the transfer of signalling messages over a link between two directly-connected signalling points. MTP Level 3 (reference 23) provides functions for the reliable transfer of signalling information from one signalling end point to another. Thus, Level 3 is responsible for those functions that are appropriate to a number of signalling links, these being separable into signalling-message handling functions and signalling-network management functions.
When considering the passing of messages over a single link, it is the combination of Levels 1 and 2 that provides for the reliable transfer of signalling information. The Level 2 functions provide a framework in which the information is transferred and performs error-detection and error-correction processes; the Level 2 functions are carried out afresh on a link-by-link basis. At Level 2, information is seen as being transferred between signalling points in messages known as "signal units".
The general form of a signal unit 40 is shown in FIG. 3. As can be seen, a field 41 carrying message/data is encapsulated in a Level 2 framework comprising the following fields: a flag field; a backward sequence number field (BSN); a backward-indicator bit (BIB); a forward sequence number field (FSN); a forward-indicator bit (FIB); a length indicator field (LI); a spare field (SP); a check field; and a terminating flag field. The FSN, FIB, BSN, BIB and check fields provide error correction functionality at link level in a manner well understood by persons skilled in the art.
There are three types of signalling unit:
MSU--the Message Signal Unit--MSUs carry all service/application data sent on the SS7 network. The amount of data per MSU is limited to 273 octets maximum. PA1 LSSU--the Link Status Signal Unit--LSSUs carry information relating to the status of the link and are therefore concerned with Level 2 functions. Normally, LSSUs are only seen during the initial alignment procedure when a link is brought into service but are used at other times, for example, to stop the flow of signal units when processors are busy. PA1 FISU--the Fill-In Signal Unit--When no MSUs or LSSUs are to be sent, a signalling point continually sends FISUs. FISUs carry basic Level 2 information only, for example, the acknowledgement of the last MSU (field 41 is empty). PA1 (1) EO1 examines the dialled digits and determines that the dialled number (DN) relates to switch EO2 which is a donor EO (that is, some subscribers have been ported from this EO). Of course, carrying out this determination requires that every switch must perform an internal lookup to determine whether the DN is destined for a donor EO. PA1 (2),(3) An LNP SCP database lookup is now performed to determine if the Called Party Number CdPN is ported. This lookup is done by sending an LNP query message to the SCP in the form a TCAP/SCCP Unitdata message. Typically, this query message will be routed via an STP as illustrated. PA1 (4),(5) The SCP after performing an LNP database lookup returns an LNP response message, in the form of a TCAP/SCCP Unitdata message, containing the LRN found by the database lookup. If the customer has ported the LRN will be different from the original CdPN whereas for non-ported customers the LRN will be the same as the original CdPN (in this latter case, the response message could simply include a "not ported" indicator rather than any number). PA1 (6),(7) The LNP response message tells EO1 whether the DN is for a ported customer and, if so, the LRN of the customer. Assuming the DN is for a ported customer, EO1 routes the call based on the LRN routing tables. The chosen route will generally be via an Access Tandem as the call is destined for a different carrier. Once a route is selected, switch EO1 prepares an IAM with the following substitutions: CdPN=LRN, GAP=DN and FCI=LNP Query Done. The IAM is then transmitted. PA1 (8) When the IAM arrives at the recipient switch EO3, a check is performed on the FCI and GAP. In the present example, this check indicates that the IAM relates to a ported customer and so EO3 must substitute CdPN=GAP and then perform a lookup on the CdPN to establish the physical connection to the CPE (Customer Premises Equipment). PA1 (a) intercepting said control messages on at least one link of the signalling network and selecting from the intercepted messages at least certain of said particular messages, PA1 (b) for each selected said particular message, determining by reference to said LNP resource means whether the subscriber number forming the global title of the message is a ported number, PA1 (c) where step (b) determines the global title to be a ported number, modifying the global title in dependence on the said routing number corresponding to the ported number forming the unmodified global title, and PA1 (d) forwarding on over the signalling network the said selected particular messages. PA1 intercept means for intercepting said control messages on at least one link of the signalling network, PA1 selection means for selecting from the messages intercepted by said intercept means at least certain of said particular messages, PA1 determining means for determining, for each selected said particular message, whether the subscriber number forming the global title of the message is a ported number, PA1 global-title modifying means responsive to said determining means determining that a global title is a ported number, to modify the global title in dependence on the said routing number corresponding to the ported number forming the unmodified global title, and PA1 means for forwarding on over the signalling network the said selected particular messages.
The length indicator (LI) within each message indicates the signal unit type as follows: LI=0 means FISU; LI=1 or 2 means LSSU; and LI=3 or more means MSU.
Each MSU carries a service information octet SIO and a signalling information field. The SIO field includes a Service Indicator sub-field that defines the user part or equivalent appropriate to the message. The SIF contains the information being transferred and will generally include a routing label 43 comprising a destination point code (DPC) indicating the destination signalling end point, an originating point code (OPC) indicating the originating signalling end point, and a signalling link selection field for specifying a particular link in cases where two signalling points are linked by a multiple-link link set. The MTP 24 is not aware of the contents of the SIF other than the routing label.
SCCP Messages With Global Titles
Of interest to the present invention are certain of the messages using the SCCP. Each SCCP-level message is encapsulated in the SIF field of an MSU as is illustrated in FIG. 3. As well as the routing label 43 described above, an SCCP message comprises a message type field 45 and a number of parameters organised into three parts 46, 47, 48 according to type. Mandatory parameters of fixed length are placed in the mandatory fixed part 46. Mandatory parameters of variable length are placed in the variable mandatory part 47. Optional parameters are placed in the optional part 48.
The SCCP messages of particular interest to the present invention are those that include additional addressing information in the form of a global title; where a global title is present, it will be contained in a Called Party parameter. This parameter is included in Connection Request SCCP messages and all connectionless SCCP messages. By way of example, the connectionless Unitdata message will now be briefly described with reference to FIG. 4, the Unitdata message type being that used for service requests to SCPs as well as for other transaction-oriented message exchanges (including switch-to-switch service requests). In a Unitdata message, apart from the message type, the only mandatory fixed parameter is the protocol class parameter (in this case indicating that a connectionless service is required). The mandatory variable part comprises three parameters Called Party Number 50, Calling Party Number 51 and Data 52, the starts of these parameters being indicated by pointers placed at the beginning of the mandatory variable part. It is the Data parameter 52 that carries the message data. There are no optional parameters (and thus no optional part 48) in a Unitdata message.
The Called Party Number parameter 50 contains addressing information additional to that contained in the routing label 43. Parameter 50 comprises an address portion 53 including one or more address elements, and an address indicator portion 54 with information about the contents of the address portion 53. The address elements that may be included in the address portion 53 are a signalling point code 55 indicating the final destination signalling point of the message, a subsystem number 56 indicating the destination functional entity for the message at the destination signalling point, and a global title 57 generally in the form of a telephone number compliant with a particular numbering plan. The address indicator portion comprises a point code indicator (PC IND) indicating the presence or absence of the address element 55, a subsystem number indicator (SSN IND) indicating the presence or absence of the address element 56, a global title indicator indicating the presence or absence of the address element 57 and its contents if present, and a routing indicator (RTG IND) indicating whether routing is to be carried out on the basis of the global title or on the basis of the destination point code in the MTP routing label and the subsystem number address element 56.
As indicated by its name, a global title identifies a destination globally within the telecommunications system concerned. The global title address element 57 in its simplest form illustrated in FIG. 4, comprises a nature of address indicator 58 and the global title address 59 itself; the indicator 58 serves to indicate whether the global title is a subscriber number, a national significant number or an international number. The global title address element 57 may also include translation type, numbering plan and encoding scheme information.
When an SCCP message is routed through the signalling system, the point code of the final destination may not be known to the sending entity but may need to be determined along the way from the global title information contained in the message (assuming the latter is of a type including the Called Party parameter with global title information). In this case, the message must be routed in two or more hops at the MTP routing level; in other words, the message is, for example, initially sent with the MTP DPC (destination point code) set to indicate an STP that has a gateway role between the originating and destination local exchange carriers, and then the DPC is changed at the STP to the point code of the next hop destination (which may be the intended final destination). The identity of the final destination is contained in the SCCP global title and in order to correctly forward on the SCCP message, the STP must carry out a global title translation to derive the required DPC for the next MTP hop; this translation is generally done by means of a lookup table. The size of the required lookup table will depend on the number of digits of the global title that need to be considered. Thus, for example, in the USA although the national numbering plan is based on ten digits, the organisation and significance of these digits has in the past meant that global title translation typically needed take account of the first six digits only. More particularly, the first three digits indicate the local exchange carrier (LEC), the second three the LEC switch (or other resource) concerned, and the final four digits indicate a particular subscriber line of the indicated LEC switch. Because SCCP messages are intended for a resource such as a switch rather than a particular subscriber line (though, course, they may relate to such a line), the last four digits of the ten digit global title could in the past be disregarded for the purposes of global title translation; indeed, generally only the first six digits were used for the global title.
However, with the advent of local number portability, the issue of global title translation has become more complex as identification of the destination resource may need all ten digits (in the case of the US numbering plan) of the global title as will be more fully explained below. The present invention is concerned with global title translation in systems supporting local number portability. In order to further place the present invention appropriately in its context, a short description will next be given of local number portability.
Local Number Portability
Local Number Portability (LNP) has become a regulatory requirement in the USA. LNP is intended to allow subscribers to move between LECs (Local Exchange Carriers) whilst retaining their existing telephone numbers, within a rating area.
AT&T has proposed an LNP solution using a Location Routing Number (LRN). This solution relies on switched-based triggers to reference service control functionality in standard manner. The solution requires modification to the ISUP IAM message to add in a Generic Address Parameter (GAP) and a Forward Call Indicator (FCI). The general operation of the LRN number portability proposal will become clear from the following description given with reference to FIG. 5.
In FIG. 5, party A is connected to switch EO1 of carrier C1 ("EO" standing, of course, for "End Office"). Party B was previously connected to switch EO2 of carrier C1 but has now ported (moved) to carrier C2 and is currently connected to switch EO3 of carrier C2. Before B ported to carrier C2, B's number was "708-444-1234", the "708-444" part of this number indicating the switch; when A dialled B, the switch EO1 simply routed the call direct to switch EO2 based on the "444" part of the dialled number. After B has ported, B is connected to switch EO3 which is identified by "708-555". The objective of number portability is to enable A to continue to dial B using the number "708-444-1234" (it being appreciated that the "708" part of the number will not need to be dialled by A). The operations that follow the dialling of "444-1234" by A will now be described, these operations being indicated by bracketed reference numbers in FIG. 5:
It will be appreciated that a switch-based implementation of the above LNP scheme requires significant modification to the switch software together with extensive validation testing of the modified software. In order to avoid this, our copending UK patent application no. 9604379.9 filed Feb. 26, 1996 proposes an LNP arrangement based on LRNs which is implemented by means of programmable message substitution units that are inserted into the signalling links and effect LNP lookups on any IAMs detected (unless such a lookup has already been done).
The introduction of LNP represents a major change for PSTNs since it breaks the traditional correlation between a dialled number and the geographical location (or at least network location) of the called party. Unfortunately, it is not only switches that are affected by this, but also any network element, such as an STP, that may need to effect SCCP message routing based on global titles. Thus considering again the case of a global title made up of a ten digit US telephone number, the final destination of the message concerned (for example, a switch) will no longer necessarily be given by the first six digits and it may be necessary to take all ten digits to identify the message destination. This obviously has a significant impact on the size of the translation tables needing to be kept by entities such as STPs and, of course, it requires modification to the related software.
It is an object of the present invention to obviate the need to upgrade STPs and other network elements effecting global title translation, in order to enable them to cope with the consequences of LNP.